home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-x400ops-postmaster-02.txt < prev    next >
Text File  |  1993-07-19  |  11KB  |  317 lines
  1.  
  2.  
  3.  
  4.  
  5.           draft-ietf-x400ops-postmaster-02.txt        x400ops Working Group
  6.           INTERNET DRAFT                                          July 1993
  7.  
  8.  
  9.  
  10.                      Postmaster Convention for X.400 Operations
  11.  
  12.                             Thu Jul 15 09:50:14 CDT 1993
  13.  
  14.  
  15.                                   C. Allan Cargille
  16.                                University of Wisconsin
  17.                              Allan.Cargille@cs.wisc.edu
  18.  
  19.  
  20.  
  21.  
  22.  
  23.           This draft document is being circulated for comment.
  24.  
  25.           If consensus is reached it may be submitted to the RFC editor as
  26.           a Proposed Standard protocol specification, for use in X.400 in
  27.           the Internet.
  28.  
  29.           Please send comments to the author, or to the IETF OSI X.400
  30.           Operations Working Group mailing list
  31.           <ietf-osi-x400ops@cs.wisc.edu>.
  32.  
  33.           This document is an Internet Draft.  Internet Drafts are working
  34.           documents of the Internet Engineering Task Force (IETF), its
  35.           Areas, and its Working Groups.  Note that other groups may also
  36.           distribute working documents as Internet Drafts.
  37.  
  38.           Internet Drafts are draft documents valid for a maximum of six
  39.           months.  Internet Drafts may be updated, replaced, or obsoleted
  40.           by other documents at any time.  It is not appropriate to use
  41.           Internet Drafts as reference material or to cite them other than
  42.           as a "working draft" or "work in progress."
  43.  
  44.           Please check the I-D abstract listing contained in each Internet
  45.           Draft directory to learn the current status of this or any other
  46.           Internet Draft.
  47.  
  48.           Abstract:
  49.  
  50.                Both RFC822 and RFC1123 (Host Requirements) require that the
  51.                email address "postmaster" be supported at all hosts.  This
  52.                paper extends this concept to X.400 mail domains which have
  53.                registered RFC1327 mapping rules (and therefore which appear
  54.                to have normal RFC822-style addresses).  It also requires
  55.                supporting a postmaster address at the ADMD and PRMD levels.
  56.  
  57.  
  58.  
  59.  
  60.           Cargille              Expires January, 1994              [Page 1]
  61.  
  62.  
  63.  
  64.  
  65.  
  66.           DRAFT              X.400 Postmaster Convention          July 1993
  67.  
  68.  
  69.           1.  Postmaster Convention in RFC822
  70.  
  71.           Operating a reliable, large-scale electronic mail (email) network
  72.           requires cooperation between many mail managers and system
  73.           administrators.  As noted in RFC822 [1], often mail or system
  74.           managers need to be able to contact a responsible person at a
  75.           remote host without knowing any specific user name or address at
  76.           that host.  For that reason, both RFC822 and the Internet Host
  77.           Requirements [2] require that the address "postmaster" be
  78.           supported at every Internet host.
  79.  
  80.           2.  Postmaster Convention and X.400
  81.  
  82.           However, RFC822 is not the only email protocol being used in the
  83.           Internet.  Some Internet sites are also running the X.400 (1984)
  84.           email protocol [3].  In the near future, the 1988 X.400 protocol
  85.           is also expected to be in use [4].  RFC1327 specifies how to map
  86.           between X.400 and RFC822 addresses [5].  When mapping rules are
  87.           used, addresses map cleanly between X.400 and RFC822.  In fact,
  88.           it is impossible to determine by inspecting the address whether
  89.           the recipient is an RFC822 mail user or an X.400 mail user.
  90.  
  91.           A paper by Rob Hagens and Alf Hansen describes an X.400 community
  92.           known as the "Global Open MHS Community" (GO-MHS) [6].  Many mail
  93.           domains in the GO-MHS Community have registered RFC1327 mapping
  94.           rules.  Therefore, users in those domains have RFC822-style email
  95.           addresses, and these email domains are a logical extension of the
  96.           RFC822 Internet.  It is impossible to tell by inspecting a user's
  97.           address whether the user receives RFC822 mail or X.400 mail.
  98.  
  99.           Since these addresses appear to be standard RFC822 addresses,
  100.           mail managers, mailing list managers, host administrators, and
  101.           users expect to be able to simply send mail to
  102.           "postmaster@domain" and having the message be delivered to a
  103.           responsible party.  When an RFC1327 mapping rule exists, the
  104.           X.400 address element corresponding to the left-hand-side
  105.           "postmaster" is "Surname=Postmaster" (both 1984 and 1988).
  106.           However, neither the X.400 protocols, North America X.400
  107.           Implementor's Agreements [7], nor the European X.400
  108.           Implementor's Agreements [8] require that "Surname=Postmaster"
  109.           and "CommonName=Postmaster" be supported.  (Supporting these
  110.           addresses is recommended in X.400 (1988)).
  111.  
  112.           For mapped X.400 domains which do not support the postmaster
  113.           address(es), this means that an address such as
  114.           "user@some.place.zz" might be valid, yet mail to the
  115.           corresponding address "postmaster@some.place.zz" fails.  This is
  116.           frustrating for remote administrators and users, and can prevent
  117.           operational problems from being communicated and resolved.  In
  118.           this case, the desired seamless integration of the Internet
  119.           RFC822 mail world and the mapped X.400 domain has not been
  120.           achieved.
  121.  
  122.  
  123.  
  124.           Cargille              Expires January, 1994              [Page 2]
  125.  
  126.  
  127.  
  128.  
  129.  
  130.           DRAFT              X.400 Postmaster Convention          July 1993
  131.  
  132.  
  133.           The X.400 mail managers participating in the Cosine MHS Project
  134.           discussed this problem in a meeting in June 1992 [9].  The
  135.           discussion recognized the need for supporting the postmaster
  136.           address at any level of the address hierarchy where these are
  137.           user addresses.  However, the group only required supporting the
  138.           postmaster address down to certain levels of the O/R Address
  139.           tree.  This approach solved part of the problem, but not all of
  140.           it.  A more complete solution is required.
  141.  
  142.           3.  Proposed Solution
  143.  
  144.           To fully achieve the desired seamless integration of email
  145.           domains for which RFC1327 mapping rules have been defined, the
  146.           following convention must be followed,
  147.  
  148.               If there are any valid addresses of the form
  149.               "user@domain", then the address "postmaster@domain" must
  150.               also be valid.
  151.  
  152.           To express this in terms of X.400:  For every X.400 domain for
  153.           which an RFC1327 mapping rule exists, if any address of the form
  154.  
  155.               Surname=User; <Other X.400 Address Elements>
  156.  
  157.           is a valid address, then the address
  158.  
  159.               Surname=Postmaster; <Same X.400 Address Elements>
  160.  
  161.           must also be a valid address.  If the X.400 system is running
  162.           X.400(1988), then the address
  163.  
  164.               CommonName=Postmaster; <Same X.400 Address Elements>
  165.  
  166.           must also be supported.  (Note that CommonName=Postmaster will
  167.           not be generated by RFC1327 mappings, but it is recommended in
  168.           the 1988 X.400 standard).
  169.  
  170.           To remain consistent with RFC822, "Mail sent to that address is
  171.           to be routed to a person responsible for the site's mail system
  172.           or to a person with responsibility for general site operation."
  173.           [10]
  174.  
  175.           3.1.  Software Limitations
  176.  
  177.           If software is unable to support this requirement, it should be
  178.           upgraded.  X.400 software developers are strongly encouraged and
  179.           requested to support forwarding mail to a centralized postmaster
  180.           mailbox in products.
  181.  
  182.           It may be possible to support forwarding postmaster mail to a
  183.           central mailbox in software packages which do not explicitly
  184.           support it by applying workaround solutions.  For example, some
  185.           packages support creating a mailing list for "postmaster" which
  186.  
  187.  
  188.           Cargille              Expires January, 1994              [Page 3]
  189.  
  190.  
  191.  
  192.  
  193.  
  194.           DRAFT              X.400 Postmaster Convention          July 1993
  195.  
  196.  
  197.           has one entry that points to the desired centralized postmaster
  198.           mailbox.  Alternatively, it may be possible to support a
  199.           postmaster address using the X.400 Autoforwarding feature.  The
  200.           software package may also support rewriting the address in some
  201.           other way.
  202.  
  203.           4.  Postmaster Support at the MD level
  204.  
  205.           Section 3 discusses the X.400 postmaster convention in terms of
  206.           X.400 addresses that map into the RFC822 mail world.  It is also
  207.           desirable to introduce an X.400 postmaster convention that is
  208.           based on the X.400 model.  This convention is as follows:
  209.  
  210.               If addresses of the form
  211.  
  212.                   C=xx; ADMD=yy; PRMD=zz; ...
  213.  
  214.               are documented in a GO-MHS Domain Document (see [11]),
  215.               and if the PRMD is under the administrative control of an
  216.               organization in the GO-MHS community, then the address
  217.  
  218.                   C=xx; ADMD=yy; PRMD=zz; S=postmaster
  219.  
  220.               must be valid and supported.
  221.  
  222.               Similarly, if addresses of the form
  223.  
  224.                   C=xx; ADMD=yy; ...
  225.  
  226.               are documented in a GO-MHS Domain Document, and if the
  227.               ADMD is under the administrative control of an
  228.               organization in the GO-MHS community, then the address
  229.  
  230.                   C=xx; ADMD=yy; S=postmaster
  231.  
  232.               must be valid and supported.
  233.  
  234.               If the PRMD or ADMD is running X.400(88), then the
  235.               address
  236.  
  237.                   CN=Postmaster
  238.  
  239.               must also be valid and supported.
  240.  
  241.           ADMDs and PRMDs that are not under the administrative control of
  242.           an organization in the GO-MHS community are also encouraged to
  243.           implement this convention.
  244.  
  245.           5.  Acknowledgements
  246.  
  247.           This document is a product of discussion and comments from the
  248.           IETF OSI X.400 Operations working group.  Helpful input was also
  249.           received from the European MHS Managers.  Thanks to Marko
  250.  
  251.  
  252.           Cargille              Expires January, 1994              [Page 4]
  253.  
  254.  
  255.  
  256.  
  257.  
  258.           DRAFT              X.400 Postmaster Convention          July 1993
  259.  
  260.  
  261.           Kaittola, who identified software limitations in supporting
  262.           postmaster.
  263.  
  264.           6.  Author's Information
  265.  
  266.           Allan Cargille
  267.           Associate Researcher
  268.           Computer Sciences Department
  269.           University of Wisconsin-Madison
  270.           1210 West Dayton Street
  271.           Madison, WI   53706   USA
  272.  
  273.           Internet: cargille@cs.wisc.edu
  274.           X.400:    S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;
  275.  
  276.           Voice +1 (608) 262-5084
  277.           Fax   +1 (608) 262-9777
  278.  
  279.           7.  References
  280.  
  281.           [1]  RFC822
  282.  
  283.           [2]  RFC1123
  284.  
  285.           [3]  X.400 (1984)
  286.  
  287.           [4]  X.400 (1988)
  288.  
  289.           [5]  RFC1327
  290.  
  291.           [6]  presently draft-ietf-x400ops-mgtdomains-ops-04.txt
  292.  
  293.           [7]  NIST X.400 Implementors Agreements
  294.  
  295.           [8]  EWOS X.400 Implementors Agreements
  296.  
  297.           [9]  Minutes from June 1992 Cosine MHS Managers Meeting
  298.  
  299.           [10] RFC822, direct quote
  300.  
  301.           [11] RFC 1465
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.           Cargille              Expires January, 1994              [Page 5]
  317.